iT邦幫忙

2021 iThome 鐵人賽

2
Software Development

系統與服務雜談系列 第 33

淺談DevOps & Observability

  • 分享至 

  • xImage
  •  

公司內部分享

公司20年老系統+傳統組織, 正面臨數位轉型中
團隊管理與開發定義SLO目標
DevOps這文化帶給傳統開發團隊的新思維與習慣
紀錄,監控與可觀測性帶給開發與維運雙方團隊的好處

文章連結

Talking About DevOps & Observability


Outline

  • 運維盲區Operational Blindness
  • 監控Monitoring
  • 紀錄Logging
  • 指標Metrics
  • Observability

前言

主要針對公司內部現況做分享.
站在DevOps的右側, 偏運維角度看事情
Observability的部分只是介紹


Operational Blindness


War Story


Note:
某天中午, 運維組內暴發出警報通知, 一堆訊息湧現. 大家也跳了起來, 發現網站癱瘓了, 外部監控近幾次健康檢查都沒過, 而觸發了警報.



Note:
發現網站癱瘓了


Black-Box Monitoring


Note:
登入主機監控系統, 發現網站的系統指標正常, 記憶體也還有, CPU沒到100%, Disk跟IO也還在容許範圍內, 資料庫也活著



Note:
不知道原因只好把問題擴大到開發團隊, 因為主機與網站服務的進程本身看起來還算正常



Note:
開發團隊也不確定要看什麼, 且它們沒有直接登入正式環境主機的權限; 也不會讓所有人都有權限進入主機, 管理成本高與資安風險高



Note:
開發團隊只好與運維團隊一起工作並且只能發號施令
最終在資料庫上發現, 一堆慢查詢跟一堆連線處於CLOSE_WAIT狀態
在Web服務上也看到有幾乎一樣多數量的進程
推測很可能Web服務已經達到了最大處理容量並停止響應新的request(例如healthcheck)
最後把db的query session都砍掉, Web服務上的請求隊列也清空, 就正常了



Note:
查找這些問題的根源, 浪費了很多時間;
當問題被升級時, 被波及的人也沒足夠權限查看對找問題有用的主機資訊與服務資訊.
最終還是得依賴運維團隊.且在這種情境下, 每一分鐘的無法服務或停機時間都是要錢的
運維團隊之所以只能把問題擴大, 是因為他們能看到的就幾乎只有主機的監控指標,


Question

  • Dev/Ops團隊的分離, 這樣的組織與溝通方式, 有間接成本的產生
    Note:
    傳統的結構上, 有一條明顯的紅線把開發與運維的職責劃分開.
    運維團隊負責主機與基礎設施, 使得應用程式的交付成為可能.


Note:
Developer與Operations如果組織結構與合作方式上職責分的太開, 往往會像拔河一般, 分散了力道.
相互拉扯中, 復原時間就流逝了.



Note:
最可怕的還是, 使用者對平台提供的服務品質沒信心了, 跳去競品平台了


DevOps

What is SRE | Tasks and Responsibilities of an SRE | SRE vs DevOps

Note:
Developer與Operations不應該相互拉扯在拔河, 而分散了眾人的力道.



非同步系統的服務水準保證 淺談非同步系統的 SLO 設計-91APP

Note:
SLI(service level indicator)
指的是指標,例如:QPS,TPS,Duration,準確性,延遲,性能等

不是所有的metric都視為SLI,選擇儘可能少的SLI,但這些SLI卻能說明服務是否穩定,可靠。

SLO(service level objective):服務等級目標
指的是一段時間內的目標,例如:1個月內的QPS 99.99%,響應時間<10ms等等

SLO是一組值的範圍,這個值就是由SLI定義的服務級別數值。自然的SLO定義就是,某SLI在正常情況下需要小於某值或者處於某個大小值之間。
選擇一個合適的SLO並不是一件容易的事情,當然一開始並不需要設定好這個範圍

SLA (service level agreement):服務等級協議
指的是整個協議,協議的內容包含了SLI,SLO以及恢復的方式和時間等等一系列所構成的協議


  • 基於時間的可用性

基於時間的可用性 = 系統正常運行時間 / (系統正常運行時間 + 停機時間)
SLO 99.95%, 以一年來看, 不可用佔了4小時22分鐘
SLO 99.99%, 以一年來看, 不可用佔了52分鐘


  • 基於次數合計的可用性

基於合計的可用性 = 成功請求數 / 請求數總和
SLO 99.99%, 如果一天要接受2.5M個請求, 每天錯誤個數應<250個

事件處理案例

  • 基於延遲

SLO 99% 前台每秒User訪問延遲 < 300ms

[架構師的修練] #2, SLO - 如何確保服務水準?

Monitoring


Types of Monitoring

Multi-Cloud Monitoring

Monitoring Layers


Logging

Deal with discrete events

  • Application debug or error messages
  • Audit-trail events
  • Request-specific metadata
  • Specific events
    Note:
    應用程式錯誤訊息、稽核事件、HTTP請求事件

Log Monitoring

  • Troubleshooting
  • Monitor

  • Clearly log level
  • Good log message (Structured Log)
  • Log aggregation
    Note:
    Show Loki
    單行Log, 又是JSON格式, 針對各種類型的服務定義出固定的metadata key

Defect of Log Monitor

  • Low value density
[INFO] .... initializing...
[INFO] ... request from xxx.xxx.xxx.xxx user_id xxxxxx

Note:
有價值的資訊密度太低, 很多都是第一行那樣的無價值資訊


這部影片主要講了很多
Log Cetralize and Monitor的好處
跟Log要怎清楚的表達
Logging in the age of Microservices and the Cloud


  • Write log into RDBMS
    • log如果併發寫入很高, 寫入的資料庫又是RDBMS, 併發事務量不會很高
      • 就算buffer pool加大, 也是有極限的, 也不建議
    • log字段很多種類, 索引選擇困難
    • DB真出事了, 想登入看log也沒法, 搞不好還沒寫進去
    • 很容易就是壓死DB的那根樹枝
    • 讓DB回歸, 業務狀態與資料的存儲與存取吧

Metrics

4 Golden Signals

  • Latency : time to serivce a request
  • Traffic : requests/second
  • Error : error rate of request
  • Saturation : fullness of a service
SRE-book
Observability: Metric, Logging, and Tracing, Oh My!

Note:
反映用戶體驗,衡量系統核心性能。如:系統的處理時間,作業計算系統的作業完成時間等。

反映系統的服務量。如:請求數,發出和接收的網絡封包大小等。

幫助發現和定位故障和問題。如:錯誤總量、調用服務失敗率等。

反映系統的飽和度和負載。如:系統佔用的內存、作業隊列的長度等。


  • Metrics for Prometheus
    • metric name and label sets
<metric name>{<label name>=<label value>, ...}
# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"}               721

Note:
label sets代表了這個metric name下的一個維度,可以有多個維度方便做聚合操作


Metric Types

- Counters (rate)
- Gauges (value)
- Distribution 
	- Histogram (heatmap)
	- Summary 
Observability of Distributed Systems

Note:
counter只增不減, 通常用來取得request總量, 任務完成的數量, 錯誤發生次數, 或者計算某段時間內的rate變化率; 能事前透過壓力與負載測試能取得可預期的上限, 做監控與警告;
查詢當前系統中,訪問量前10的HTTP URL.

gauge即時變化情況, 隨著時間不斷變化, 通常用來記錄cpu, mem用量, coroutine數量, pool usage, 併發請求數...;
透過計算樣本的線性回歸模型, 對數據的變化趨勢進行預測.

Histogram會對觀測數據取樣,然後將觀測數據放入有數值上界的桶中,並記錄各桶中數據的個數,所有數據的個數和數據數值總和, 請求時延, 各種有樣本數據;用來區分是平均的慢還是長尾的慢,快速了解監控樣本的分佈情況
Summary 與 Histogram 類似,會對觀測數據進行取樣,得到數據的個數和總和。此外,還會取一個滑動窗口,計算窗口內樣本數據的分位數。


Archetecture


Observability

The Observability Pipeline

Note:
Monitoring tells you whether system works, observability lets you ask why it's not working



Pilliars of Obersvability


News

【企業SRE實例:新加坡星展集團】頂尖數位銀行如何再進化,SRE轉型是變身科技公司的關鍵
【臺灣SRE實例:17Live集團】多功能型SRE化身內部信心來源,天天成為開發團隊後盾
【臺灣SRE實例:Line臺灣】如何確保Line服務天天不中斷,專責SRE扮演開發與維運的橋樑
Line臺灣百億筆遙測數據的可觀察性平臺架構大公開
臺灣大型企業如何上手SRE,Google建議先做這4件事


Reference

SRE-BOOK
Operations Anti-Patterns, DevOps Solutions
Logging and Log Management
阿里雲-日誌服務
Grafana Documentation
Prometheus
Loki Documentation
FluentBit Documentation


Thank you!

You can find me on


上一篇
Domain Storytelling - 簡單的方法說出一個Domain story
系列文
系統與服務雜談33
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言